home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 622 < prev    next >
Text File  |  1996-08-06  |  2KB  |  38 lines
  1. Newsgroups: comp.std.c
  2. Path: newsfeed.ed.ac.uk!edcogsci!richard
  3. From: richard@cogsci.ed.ac.uk (Richard Tobin)
  4. Subject: Re: Restrictions on qsort compare function?
  5. X-Nntp-Posting-Host: pitcairn
  6. Message-ID: <DoKJMJ.491@cogsci.ed.ac.uk>
  7. Sender: cnews@cogsci.ed.ac.uk (C News Software)
  8. Organization: HCRC, University of Edinburgh
  9. References: <4iokop$h4p@lyra.csx.cam.ac.uk>
  10. Date: Wed, 20 Mar 1996 13:47:06 GMT
  11.  
  12. In article <4iokop$h4p@lyra.csx.cam.ac.uk> jkb@mrc-lmb.cam.ac.uk (James Bonfield) writes:
  13. >My understanding of this is that qsort() ought to be able
  14. >to handle any sort function, even if it's something as dumb as
  15. >(rand()%3)-1.
  16.  
  17. The standard says that the function must return negative, zero or
  18. positive according to whether the first argument is less than, equal
  19. to, or greater than the second.  It is implicit in this that the
  20. comparison function defines a total order on the elements; something
  21. like (rand()%3)-1, or a<b, doesn't.
  22.  
  23. The point is that it must be consistent.  If qsort() compares two
  24. elements twice, it should get the same result each time.  If a < b
  25. then b > a.  If a < b and b < c then a < c.  Neither of the functions
  26. mentioned above has these properties.  In particular if a is less than
  27. b then a < b will return 1 but b < a will return 0 which is not
  28. negative.
  29.  
  30. I suppose this should be made explicit in the standard, if it hasn't
  31. already been.
  32.  
  33. -- Richard
  34. --
  35. "Hither turn thy steps, hither come to thy death and for Camilla
  36. receive due guerdon!  Shalt thou, even thou, die by Diana's darts?"
  37.                                               [Virgil, Aeneid X1 855-7]
  38.